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Express Mail No. EM209353178US 
Description 

METHOD AND SYSTEM FOR CUSTOMIZING FORMS 
5 IN AN ELECTRONIC MAIL SYSTEM 

Technical Field 

This invention relates to an improved method and 
system for communicating information through electronic 
10 mail system and in particular a method and system of using 
customizable forms in an electronic mail system. 

Background of the Invention 

It is common in written communications to use 
15 standard forms. Examples of standard forms are credit 
application and phone message slips. These forms allow 
for the collection of certain data in a structured format. 
This structured format simplifies the processing of the 
data . 

20 In computer systems, data is often gathered and 

displayed through the use of electronic forms. For 
example, a computer program could display a form that 
looks similar to the paper version of a credit application 
form. This similarity simplifies the entry of data into 

25 the computer and subsequent display of the data. 

An electronic mail system allows mail to be 
collected electronically through a computer terminal and 
transmitted to another computer or another user of the 
same computer and displayed on a terminal. Typical mail 

3 0 systems use certain standard forms. For example, the 
standard send message form 100 as shown in Figure 1 has a 
to field 101 into which the user enters the recipient of 
the mail messages and a re field 102 into which the user 
enters the subject of the mail. The send message form 100 

3 5 also has text field 103 into which the user enters the 
body of the message. A mail system would typically have 
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an analogous receive message form for displaying a 
message . 

A few mail systems have allowed the user to add 
custom forms. These mail systems provide only limited 
5 customization o The customization is typically limited to 
the use of predefined components. For example, the forms 
designer could specify where to place a text field or a 
date field. However, the mail system predefines how the 
fields will operate. When a user of a form presses a key 
10 or uses a mouse button to click on a component of a form, 
the mail system will typically take one or more actions in 
response to that input. The actions taken when a button 
field is clicked, for example, is referred to as the 
"behavior" of the button. Each form component in custom 
15 forms traditionally has a single behavior or a fixed 
number of possible predefined behaviors. 

While this limited customization allows for some 
degree of user-customization of electronic mail forms, the 
user is limited to the predefined components and 
20 behaviors. 

Summary of the Invention 

It is an object of the present invention to 
provide a method and system for customizing forms in an . 

25 electronic mail system. 

It is another object of the present invention to 
provide an electronic mail system in which the user of the 
mail system can specify the field layout of a custom form 
and specify the behavior of the fields in the custom form. 

30 It is another object of this invention to 

provide an electronic mail system that collects data 
through a custom form, packs the data into a mail message, 
and transports the mail message to the specified 
recipients of the mail. 

35 It is another object of this invention to 

provide an electronic mail system that receives mail 



messages, unpacks the data from the mail message, and 
displays the data in a custom form. 

It is another object of the present invention to 
provide an electronic mail system with a transaction event 
5 processor to receive mail events and to call a form 
control procedure to implement the behavior of the custom 
form. 

It is another object of the present invention to 
provide a layout for a form data structure that includes 
10 the definition of the form fields and the form control 
procedure . 

Brief Description of the Drawings 

Figure 1 shows an example of a typical send 
15 message form. 

Figure 2 shows the components of a mail system 
that implements custom forms. 

Figure 3 shows an example of a custom form. 

Figure 4 shows the layout of the form data 

20 structure. 

Figure 5 is a flow diagram of the main routine 
of the TREV. 

Figure 6 is a flow diagram of subroutine 
FCPrequest . 

25 Figure 7 is a flow diagram of subroutine 

MouseEvent . 

Figure 8 is a flow diagram of subroutine 
Current Field . 

Figure 9 is a flow diagram of subroutine 
3 0 KeyboardEvent . 

Figure 10 is a flow diagram of subroutine 
Enable/Disable . 

Figure 11 is a flow diagram of subroutine 

PackEvent . 

35 Figure 12 is a flow diagram of subroutine FCP. 

Figure 13 is a flow diagram of subroutine 

f ormNew. 



Figure 14 is a flow diagram of subroutine 

fieldPre. 

Detailed Description of the Invention 
5 In a preferred embodiment of the present 

invention, an electronic mail system implements user- 
customizable forms that allow the user to define form 
components and their behavior- This invention allows a 
user to specify the layout of a custom form and specify a 
10 form control procedure (FCP) to control the behavior of 
the form components. The FCP is a computer subroutine 
that implements user-defined processing of the form. The 
form is defined in a form data structure that contains the 
layout of the form and the FCP. The mail system interacts 
15 with the FCP to collect form data and transmit the data to 
a receiver. The mail system also interacts with the FCP 
tH' to display the message through the custom form when it is 

received. 

D In a preferred embodiment, the mail system has a 

y 20 transaction event manager (TREV) that calls the FCP. The 

p TREV creates a window for the form and displays the form 

'p_ in the window. When certain events occur, such as 

keyboard entry, for the window, the TREV calls the FCP. 
This calling allows the FCP to perform custom processing. 
25 Figure 2 shows the components of a mail system 

that uses custom forms. The mail system 201 contains the 
TREV 202. The TREV accesses the form data structure 203 
to display the form window 204. The mail system 201 
receives input from the keyboard 205 and mouse 206. The 
30 mail system 201 packs the message data into mail message 
format and transports the message to the recipient via 
electronic mail link 207. The mail system 201 also 
receives mail messages via electronic mail link 207 and 
unpacks the messages. 
35 Figure 3 shows an example of a custom mail 

message form. The form 3 00 is designed to handle library 
requests. The form 3 00 contains picture 3 01 that is 
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suggestive of the function, field 3 02 that is a scroll 
list in which the user selects the recipient's names, 
subject field 303 which is a text field, request field 304 
which is a scrolling text field, check boxes 3 05 which 
5 select the source, other field 306 which is a text field, 
radio button fields 307 which select the delivery means, 
and send button field 308 which allows the user to 
indicate that the message is to be sent* 

10 Form Data Structure 

A custom form is defined in a form data 
structure. The form data structure describes the design 
and layout of the form. It describes the initial size of 

15 the form and initial placement of the form on the display. 
It describes the placement of predefined form components, 
such as buttons and text fields, and the placement and 
appearance of user-defined form components. The 
appearance of user-defined form components may be defined 

20 as an arbitrary bitmap image. Figure 4 shows the layout 
of the form data structure of a preferred embodiment. The 
form comprises four types of elements: form header, field 
object, form control, and form control procedure. In a 
preferred embodiment, the elements have variable lengths 

25 and have a primary and secondary key to allow fast 
retrieval of the elements. Alternatively, the FCP could 
be stored separate data structure. 

Form Header 

30 

The form header contains information describing 
the window in which the fields are displayed. The form 
data structure contains only one form header which is the 
first entry in the form data structure. The primary key 
35 of the form header is "FHDR" and the secondary key is 0. 
The following data structure, as specified in the "C" 



programming language, defines a preferred format of form 
header. 

typedef struct FormHdr 
5 { 

char f ormFlags ; 

char formProcId; 
Rect f ormCoords ; 

short fonnCurField; 
10 unsigned char formTitle[]; 

} FormHdr, *FormHdrPtr 

The variable f ormFlags specifies automatic 
positioning of the window and controls the appearance of 

15 the window. The variable formFlags can be set to a 
combination of values as described in the following. The 
variable formFlags is set to the value ffNoFlags to 
indicate that variable formCoords contains the coordinates 
of the window and variable formProcId contains the style 

20 of the window. The variable formFlags is set to the value 
ffTBCentre to indicate that the window is to be centered 
vertically. The variable formFlags is set to the value 
ffLRCentre to indicate that the window is centered 
horizontally. The variable formFlags is set to the value 

25 f fTBLRCentre to indicate that the window is centered both 
vertically and horizontally. The variable formFlags is 
set to the value ffAtBottom to indicate that the window is 
to be placed at the bottom of the screen. The variable 
formFlags is set to the value ffNoMaillcon to indicate 

3 0 that the mail icon is not to be drawn oh the title bar. 
The variable formFlags is set to the value ffModal to 
indicate that the window is modal. The variable formFlags 
is set to the value ffGoAway to indicate that the window 
has not go away box. 

35 The variable formProcId specifies the style of 

window. In a preferred embodiment the style can be 
modeless or modal. 

The variable formCoords specifies the screen 
position and size of the form window. This positioning 
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information can overridden by the setting of variable 
f ormFlags . 

The variable formCurField is used internally by 
the TREV to store what field is current. 
5 The variable formTitle is a string that is 

displayed in the title bar of modeless form windows. 

Field Objects 

10 A form consists of a number of fields. Each 

field object describes the characteristics of a field of 
the form. For each field there is one field object in the 
form data structure. The primary key of a field object is 
"FFLD" and the secondary key is set to a unique identifier 

15 for that field; typically , the identifier would be a 
descriptive of the field. For example, an address field 
may have a secondary key equal to "ADDR." The following 
data structure defines a preferred format of the field 
objects. 

20 

typedef struct FldHdr 
{ 

short type; 
unsigned short attributes; 

2 5 Rect coords; 

unsigned short keyEquiv; 
PackedFont font; 
Handle data; 
Handle private; 

3 0 unsigned char initData[]; 
} FldHdr, *FldHdrPtr; 

The variable type indicates the type of the 
field. The fbO^lowing describes some preferred standard 
35 field types. One filled in the art would know that other 
standard field types earn be defined. The variable type is 
set to the value f ieldSt^icText to indicate that the text 
in the field cannot be edifeed. The variable type is set 
to the value f ieldEditText tc$\indicate that the text in 
40 the field can be edited, for ex^iple, subject field 303. 
The variable type is set to the veMiie f ieldHiddenText to 
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indicate that the text in the field can be edited but is 
not \choed to the display. The variable type is set to 
the vklue fieldButton to indicate that the field is a 
standardv button, for example, button field 308. The 
5 variable \type is set to the value f ieldRadioButton to 
indicate that the field is a standard radio button, for 
example, radio button fields 307. The variable type is 
set to the Value f ieldCheckBox to indicate that the field 
is a standard, check box, for example, check boxes 305. 
10 The variable tVp e is set to the value f ieldButtonlcon to 
indicate that the field displays a button in the shape of 
q the specified icoh. The variable type is set to the value 

5 f ieldOptionButton \to indicate that the field displays a 

J button with a specified title string. The variable type 

w 15 is set to the valuA fieldTime to indicate that the field. 

:£ displays the time of \day. The variable type is set to the 

m value fieldDate to indicate that the field displays the 

l m date. The variable tytae is set to the value fieldRect to 

}S indicate that a rectangle is drawn around the field. The 

D 20 variable type is set to >the value fieldPicture to indicate 

% that the field displays the specified picture, for 

=J example, picture 301. The variable type is set to the 

value f ieldVariableData ta indicate that field contains 
data that is not displayed\ on the screen. The variable 
25 type is set to the value freldUser to indicate that the 
field is a user-defined field.\ 

The variable attributes specifies the appearance 
and behavior of the field. One skilled in the art would 
know that other values for the variable attributes could 
30 be defined to specify different appearances and behaviors. 
The variable attributes is set to the value 
attrCanBeCurrent to indicate that the field can be the 
current field. The current field is the field that 
receives characters entered by the user. The variable 
35 attributes is set to the value attrlnform to indicate that 
the FCP is to be called by the TREV whenever the field is 
affected by a u^er event, such as, a mouse click or entry 
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of a character (if the field is current). The variable 
attributes is set to the value attrPack to indicate that 
the field contents will be packed into the mail message 
when a send message request is detected by the mail 
system, for example, when the user clicks button field 
308. The variable attributes is set to the value attrldle 
to indicate that the FCP will be called periodically. 
This periodic calling allows fields, such as a time field, 
to be updated. The variable attributes is set to the 
value attrReadOnly to indicate that the field is read 
only. The variable attributes is set to the value 
attrDisabled to indicate that the field is drawn 
differently to indicate that it is disabled (usually 
grey). The variable attributes is set to the value 
15 attrGroupl, attrGrou P 2, attrGroup3, or attrGrou P 4 to 
indicate that the field is in an attribute group. The 
variable attributes is set to the > value 
attrDependCheckState, attrDependSetState, or 

attrDependSetNegStata to define the functioning of a 
0 group. a group of fields allows for the enabling and 
disabling of fields within the group based on whether 
other fields in the group contain data. When data is 
entered or deleted from a field, the TREV checks all the 
fields in the group that have the variable attributes set • 
>.5 to the value attrDependCheckState set. if all these 
fields have data, then the TREV enables all the fields in 
the group that have the variable attributes set to 
attrDependSetState and disables all the fields in the 
group that have the variable attributes set to 
0 attrDependSetNegState. 

The variable coords contains the coordinates of 
the rectangle that defines the field in the window. 

The variable keyEquiv contains the keyboard 
equivalent for many types of fields, such as a button 
5 field. 

The variable font contains the font, face, and 
size of the text that is displayed in the field. 
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The variables data and private are handles that 
are used at run time to store information about the field. 

Form Control 

.The form control fields are a special class of 
fields that are not referenced or modified by the TREV. 
The field serves to store global variables for an FCP. 
The variables are preserved between calls to the FCP. The 
primary key is "FDAT" and the secondary key is a unique 
identifier for the field. 



Form Control Procedure 

& / 15 ThesForm Control Procedure (FCP) is a computer 

subroutine routine that is called directly by the TREV. 
The FCP written\by the forms designer to implement form 
customization. Th\ FCP is a block of code stored as the 
last entry in the f^rm data structure. m a preferred 
20 embodiment, the FCP written in assembly language or 

another programming langiW that is compiled into machine 
code. Alternatively, the FCP can be written in a 

scripting language or pseddo-machine language that is 
interpreted. The use of a scripting language or pseudo- - 
25 machine language would facilitate platform independent 
custom forms. In a preferred embodiment, the FCP has full 
access to the computer resources. \Alternatively , the FCP 
could be restricted as to the resourced used. For 
example, the FCP could be restricted to the operating 
system calls available to it. The primary key of the FCP 
is "FFCP" and the secondary key is zero\ The following 
defines the format of the call to the FCP. 

35 Hg)* 1 ° SErr (UE>Ca11 ' cal lType, win\ident, req, 
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ProcPtr UpCall; 
short callType; 
WindowPtr win; 
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long ident; 
short req; 
long arg; 

5 

The parameter UpCall is an address of a 
procedure that can be called by the FCP. This parameter 
provides a convenient mechanism for allowing the FCP to 
access the internal functions of the mail system. For 

10 example, the mail system may support a field type defined 
as a list, for example, to field 302. The mail system may 
have routines, such as an add-item-to-list routine, to 
manipulate lists. The FCP can access these routines 
through the procedure pointed to by the parameter UpCall. 

15 The parameter callType specifies what particular 

action the FCP is asked to perform. The parameter 
callType can be set to the following values: f cpFormEvent, 
fcpFieldPre, f cpFieldPost, or f cpUserField. 

The parameter callType is set to the value 

20 fcpFormEvent to allow the FCP to deal with form-specific 
events. A form-specific event would be global 

initialization of FCP internal variables. When the 
parameter callType is set to fcpFormEvent the parameter 
req specifies the type of form event. The parameter req 

25 is set to the value formNew to permit the FCP to 
initialize its global data and allocate any other data 
structures it may require. The FCP is called with this 
parameter value after the individual fields have been 
initialized. The parameter req is set to the value 

3 0 fonnDispose to permit the FCP to dispose of any memory 
manager data structures that have been allocated. The FCP 
is called with this parameter value before the individual 
fields have their associated dispose functions performed." 
The parameter req is set to the value formldle to permit 

35 the FCP to perform idle processing, such as updating a 
time field. The FCP is called with this parameter value 
before the idle messages are sent to the individual 
fields. The parameter req is set to the value formPack to 



notify the FCP that the individual fields have been packed 
into the mail message . The FCP can change the packed data 
or add additional data to the mail message. The parameter 
req is set to the value formUnpack to notify the FCP that 
5 the individual fields have been unpacked. The FCP can 
modify the unpacked data. 

The parameter callType is set to the value 
fcpFieldPre to allow the FCP to perform customization 
before the TREV performs its standard functions for an 

10 event, such as keyboard entry. When the FCP returns to 
the TREV, the FCP can -set the result code to the value 
TErrDealtWith to indicate that the TREV is to skip its 
standard processing for this event. 

The parameter callType is set to the value 

15 fcpFieldPost to allow the FCP to perform customization 
after the FCP performs it standard functions for an event. 

The parameter callType is set to the value 
fcpUserField to allow the FCP to perform customization for 
a user-defined field. 

20 The parameter win contains a pointer to the 

window in which the form is displayed. 

The parameter ident contains the identification 
of the field, which in a preferred embodiment is the 
secondary key from the form data structure . 

25 The parameter req contains information on the 

type of event for which the FCP is being called. One 
skilled in art would know that other event types, such as 
list processing events, could be defined. The FCP is 
called with the parameter req set to the value reqCreate 

3 0 once for each field after a form is created. This allows 
the FCP to perform initialization associated with the 
field. The FCP is called with the parameter req set to 
the value reqDelete once for each field just before the 
form is disposed of. This allows the FCP to perform clean 

35 up for the field. The FCP is called with the parameter 
req set to the value reqUpdate for each field that needs 
to have its contents updated on the display. This allows 




13 



the FCP to redisplay data after the window has been 
uncovered. The FCP is called with the parameter req set 
to the value reqldle periodically for each field with the 
variable attributes set to the value attrldle. This 
5 allows the FCP to update fields, such as a time field. 
The FCP is called with the parameter req set to the value 
reqCurrent for a field that has been tabbed to or clicked 
upon. This allows the FCP to customize a field when it 
becomes current. The FCP is called with the parameter req 

10 set to the value reqNotCurrent when the current field 
changes. The FCP is called with the parameter req set to 
the value reqEnable to indicate that the field has become 
enabled. The FCP is called with the parameter req set to 
the value reqDisable to indicate that the field has become 

15 disabled. The FCP is called with the parameter req set to 
the value reqKey to indicated that a key has been entered 
into the field. The FCP is called with the parameter req 
set to the value reqChosen to indicate that the defined 
equivalent key as stored in variable keyEquiv for the 

20 field has been entered. The FCP is called with the 
parameter req set to the value reqMouse whenever a mouse 
down event (click) occurs. The FCP is also passed the 
location of the cursor. The FCP is called with the 
parameter req set to the value reqEdit to indicates that 

25 an edit function, such as undo, cut, copy, paste, or 
clear, is requested for the field. The FCP is called with 
the parameter req set to the value reqHasData so that the 
FCP can return a value of true if the field has data and 
false otherwise. The FCP is called with the parameter req 

30 set to the value reqGetData so that the FCP can return the 
value of the data in the field. The FCP is called with 
the parameter req set to the value reqSetData so that the 
FCP can change the data in the field. 

The parameter arg stores request-specific data. 

35 



Transaction Event Manager 
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The Transaction Event Manager (TREV) is the 
portion of the mail system that manages the events 
associated with a form. Figures 5 through 11 are a flow 
diagram of the TREV. Figure 5 is a flow diagram of the 
main TREV routine. This main routine creates a window for 
a form and then waits for events, such as, the click of a 
mouse or keyboard entry. When an event occurs, this 
routine determines the event type and calls the 
appropriate routine to process the event. In block 501, 
the routine performs the necessary interaction with the 
window manager to create a window for a form. The routine 
initializes the window in accordance with the 
specifications in the form data structure. In block 502, 
the routine calls subroutine FCP with the values 
fcpFormEvent and formNew to indicate that the form was 
just created. This call allows the FCP to perform 
customized initialization. Subroutine FCP is described 
below in detail. In block 503, the routine calls 
subroutine FCPrequest with the value reqCreate once for 
each field in the form data structure. These calls allow 
the FCP to perform custom initialization for each field. 
Subroutine FCPrequest is described below in detail. 

In blocks 504 through 519, the routine waits for 
an event to occur, determines the event type, and calls 
the appropriate routines to process the event. In block 

504, the routine waits until an event occurs. In block 

505, if the event type is idle, then the routine continues 
at block 506 to process the idle event, else the routine 
continues at block 508. In block 506, the routine calls 
subroutine FCP with the values fcpFormEvent and formldle 
to indicate that an idle event occurred. In block 507, 
the routine calls subroutine FCPrequest with the value 
reqldle once for each field in the form data structure 
that has its attribute set to attrldle. . The routine then 
loops to block 504 to wait for the next event. 

In block 508, if the event type is mouse, then 
the routine continues at block 509, else the routine 
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continues at block 510. In block 509, the routine calls 
subroutine MouseEvent to process the mouse event. 
Subroutine MouseEvent is described in detail below. The 
routine then loops to block 504 to wait for the next 
event . 

In block 510, if the event type is keyboard, 
then the routine continues at block 511, else the routine 
continues at block 512. In block 511, the routine calls 
subroutine KeyboardEvent to process the keyboard event. 
Subroutine KeyboardEvent is described in detail below. 
The routine then loops to block 504 to wait for the next 
event . 

In block 512, if the event type is update, then 
the routine continues at block 513, else the routine 
continues at block 514. In block 513, the routine calls 
subroutine FCPrequest with the value reqUpdate once for 
each field in the form data structure. The routine then 
loops to block 504 to wait for the next event. 

In block 514, if the event type is pack or 
unpack, then the routine continues at block 515 to process 
the pack or unpack, else the routine continues at block 
517. In block 515, the routine calls subroutine PackEvent 
to pack or unpack a mail message. Subroutine PackEvent is 
described in detail below. In block 516, the routine, 
calls subroutine FCP with value fcpFormEvent and value 
formPack or formUnpack, depending on the event type, to 
allow the FCP to modify the mail message data. The 
routine then loops to block 504 to wait for the next 
event . 

In block 517, if the event type is edit, then 
the routine continues at block 518 to process the event, 
else the routine continues at block 519. In block 518, 
the routine calls subroutine FCPrequest with values 
formCurField from the form data structure and reqEdit. 
The routine then loops to block 504 to wait for the next 
event . 
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In block 519, if the event type is dispose, then 
the routine continues at block 520, else the routine loops 
to block 504 to wait for the next event. In block 520, 
the routine calls subroutine FCP with values f cpFormEvent 
and formDispose. In block 520, the routine calls 
subroutine FCPreguest with the value reqDispose once for 
each field in the form data structure. The routine then 
returns . 

Figure 6 is a flow diagram of the FCPrequest 
subroutine. This subroutine controls calling the FCP 
before and after the standard processing is performed by 
the TREV. The parameters passed to this subroutine depend 
upon the request type, but typically include the field 
identification and data. In block 601, the routine calls 
subroutine FCP with the value fcpFieldPre, the passed 
request value, the field identification, and the data. 
This call allows the FCP to perform custom processing for 
the field. In block 602, if the FCP sets the result code 
to the value TErrDealtWith , then the routine continues at 
block 606, else the routine continues at block 603 to 
perform the standard processing for a field. In block 
603, if the field type is UserField, then the routine 
continues at block 605, else the routine continues at 
block 604. In block 604, the routine performs the - 
standard process for a field. For example, if the field 
is an editable text field and the event was the keyboard 
entry of a letter, then the routine would echo the letter 
to the display. The routine continues at block 606. In 
block 605, the routine calls subroutine FCP with the value 
fcpUserField and the field identification. Since there is 
no standard processing for a user-defined field, the TREV 
lets the FCP perform custom processing. The routine then 
continues at block 606. In block 606, the routine calls 
subroutine FCP with the value f cpFieldPost , the passed 
request value, the field identification, and the data. 
The routine then returns. 
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Figure 7 is a flow diagram of subroutine 
MouseEvent, which processes mouse events. The routine is 
passed the type of mouse event, such as click down, and 
the location of the cursor. in block 701, the routine 
5 determines at what field the cursor is located. In block 
702, if the attribute for that field is attrCanBeCurrent , 
then the routine continues at block 703, else the routine 
continues at block 704. in block 703, the routine calls 
subroutine CurrentField to change the current field to the 
10 field just selected by the mouse event. Subroutine 
CurrentField is described in detail below. In block 704, 
the routine calls subroutine FCPrequest with the value 
reqMouse, the location, and the field identification. The 
routine then returns. 
15 Figure 8 is a flow diagram of the subroutine 

CurrentField, which switches the current field to the 
passed field. In block 801, the routine calls subroutine 
FCPrequest with value reqNotCurrent and the formCurField 
from the form data structure. This call switches the 
20 current field to a not current status. In block 802, the 
routine sets formCurField in the form data structure to 
the passed field. in block 803, the routine calls 
subroutine FCPrequest with values reqCurrent and the 
formCurField from the data structure. This call switches 
25 the new current field to a current status. The routine 
then returns . 

Figure 9 is a flow diagram of the subroutine 
KeyboardEvent, which processes keyboard events. This 
routine is passed the keyboard event type. In block 901, 
30 if the event is a tab key, then the routine continues at 
block 902, else the routine continues at block 904. In 
block 902, the routine determines the next field in the 
form data structure that has the attribute 
attrCanBeCurrent. In block 903, the routine calls 

35 subroutine FieldCurrent to set the next field to the 
current field and the routine then returns. In block 904, 
routine determines if the keyboard event corresponds to a 
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equivalence key as defined for a field in the form data 
structure. If an equivalence is found, then the routine 
continues at block 905, else the routine continues at 
block 906. in block 905, the routine calls subroutine 
FCPrequest with the value reqchosen and the field for 
which the equivalence was found and then returns. m 
block 906, if the current field is in a group, then the 
routine continues at block 907, else the routine continues 
at block 908/ in block 907, the routine calls subroutine 
Enable/Disable to enable or disable the fields in the 
group as appropriate. Subroutine Enable/Disable is 
described in detail below. m block 908, the routine 
calls subroutine FCPrequest with the value reqKey. The 
routine then returns. 

Figure 10 is a flow diagram of the subroutine 
Enable/Disable, which enables or disables the fields in a 
group. m block 1001, the routine, starting with the 
first field in the form data structure, selects the next 
field. m block 1002, if all the fields have been 
selected, then the routine continues at block 1008, else 
the routine continues at block 1003. m blocks 1003 
through 1007, the routine determines what fields are in 
the group and whether the dependencies are satisfied. In 
block 1003, if the selected f ield . is in the group, then- 
the routine continues at block 1004, else the routine 
loops to block 1001 to select the next field. m block 
1004, the routine maintains a list of the fields in the 
group. m block 1005, if the attribute of the selected 
field is attrDependCheckState, then the routine continues 
at block 1006, else the routine loops to block 1001 to 
select the next field. m block 1006, the routine calls 
subroutine FCPrequest with the value reqHasData. In block 
1007, if the field has data, then the routine loops to 
block 1001 to select the next field, else the routine 
35 returns because the dependency failed. m blocks 1008 
through 1013, since the dependency is satisfied, the 
routine enables or disables the fields in the group. In 
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block 1008 , the routine, starting with the first field in 
the saved list of fields (which comprises the group) , 
selects the next field in the group. In block 1009, if 
there are more fields in the list, then the routine 
5 continues at block 1010, else the routine returns. In 
block 1010, if the attribute for the selected field is 
attrDependSetState, then the routine continues at block 
1011, else the routine continues at block 1012. In block 
1011, the routine calls subroutine FCPrequest with the 
10 value reqEnable to enable the field and then the routine 
loops to block 1008 to select the next field in the group. 
In block 1012 , if the attribute for the selected field is 
y attrDependSetNegState, then the routine continues at block 

1013, else the routine loops to block 1008 to select the 
W 15 next field in the group. In block 1013, the routine calls 

p subroutine FCPrequest with the value reqDisable to disable 

y} the field and the routine loops to block 1008 to select 

'f* the next field in the group. 

□ Figure 11 is a flow diagram of subroutine 

:L- 20 PackEvent, which packs or unpacks the form data into or 

m from a mail message. In block 1101 if the event type is a 

J3 pack, then the routine continues at block 1102, else the 

~~ event type is an unpack and the routine continues at block 

1105. In block 1102 through 1104, the routine packs the 
25 form data into a mail message. In block 1102, the routine 
calls subroutine FCPrequest with the value reqGetData once 
for each field in the form data structure with the 
attribute of attrPack. In block 1103, the routine packs 
the data that is returned from the request to get data 
30 into a mail message. In block 1104, the routine calls 
subroutine FCP with value formPack. This call allows the 
FCP to modify the packed mail message. The routine then 
returns. In block 1105 through 1107, the routine unpacks 
the data in the mail message. In block 1105, the routine 
35 unpacks the data from the mail message and stores the data 
in the form data structure. In block 1106, the routine 
calls subroutine FCPrequest with the value reqSetData once 
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for each field in the form data structure with the 
attribute of attrPack. In block 1107, the routine calls 
subroutine FCP with the value formUnPack to allow the FCP 
an opportunity to modify the unpacked data. The routine 
5 then returns. 

Form Control Procedure 

Figure 12 is a flow diagram of the main routine 
of a typical FCP. This flow diagram shows the procedure 

10 for determining the callType in blocks 1201 through 1204 , 
and determining the form events in blocks 1208 through 
1212. In blocks 1205 through 1207 and blocks 1212 through 
1217, the FCP calls the subroutines to process the events. 
The subroutines implement the customization of the form. 

15 Figures 13 and 14 are an example of a flow 

diagram of the routine to process the events for an FCP 
that implements\a game of tick-tack-toe. Figure 12 is the 
flow diagram forv the main routine in the FCP for this 
example. The customized form in this example works as 

20 follows. There are Vine fields in the form. Each field 
corresponds to a location in tick-tack-toe grid. The 
fields contain either no\data, an X, or an O. The first 
player would click the mouse over one of fields. The FCP 
detects that this field becsnnes the current field, draws 

25 an X in the field, and sets the data in the field to an X. 
The first player would request >that the mail system send 
the message to the second player. When the message 
arrives at the second player, the Ffc^P would draw the tick- 
tack-toe grid and draw an X in the appropriate field. The 

30 second player would move the cursor tea a field and click 
the mouse. The FCP would draw an O inv that field. The 
second player would then send the message to the first 
player. Play would continue until one of \he players win 
or all the fields contain an X or an O (a tsie) . When a 

35 player wins, the FCP draws a line through Vhe winning 
fields and prohibits the placement of any other X's or 
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O's. The FOP also prohibits placing an X or an O in a 
field that is already occupied. 

figures 13 and 14 show the flow diagrams for 
-£> 5 /subroutines \fonnNew and fieldPre that are called by the 
5 main FCP routine shown in Figure 12. This example of 
tick-tack-toe\ using customizable form could be made more 
sophisticated A for example, by allowing a player to change 
his mind before the mail is sent. Figure 13 shows the 
flow diagram fott subroutine formNew. The only function of 

10 this routine is Vo draw the tick-tack-toe grid after the 
window is created\ 

Figure 14 shows the diagram for the subroutine 
fieldPre. The subroutine performs all the substantive 
processing for the implementation of the game. In block 

15 1401, if the value in the parameter req is reqUnPack, then 
the routine initializes the grid with the current value of 
the field by continuing at block 1402, else the routine 
continues at block 14 06. In blocks 14 02 through 14 05, the 
routine draws an X or an 0 in the field that is being 

20 unpacked, as appropriate. In block 1402, if the data in 
the field is an X, then the routine continues at block 
1403, else the routine continues at block 1404. In block 
1403, the routine draws an X in the field and continues at 
block 1413. In block 1404, if the data in the field is an 

25 O, then the routine continues at block 1405, else the 
routine continues at block 1413. In block 1405, the 
routine draws an 0 in the field and continues at block 
1413. 

In block 1406, if the variable winner is set, 
30 then the routine continues at block 1407, else the routine 
continues at block 14 08. In block 14 07, the routine sets 
the result code to the value TErrDealtWith to indicate 
that the TREV will not need to perform its standard 
processing for this event. The routine then returns. 
35 In block 1408, if the value of parameter req is 

reqCurrent, then the routine continues at block 1409, else 
the routine returns. In block 1409, if data is in the 
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field, then the routine returns because an X or an O is 
already in the field, else the routine continues at block 
1410. In block 1410, if there are an even number of 
fields with data, then it is X's turn and the routine 
5 continues at block 1412, else it is O's turn and the 
routine continues at block 1411. In block 1411, the 
routine draws an 0 in the field and sets the field data 
value to indicate an O. In block 1412, the routine draws 
an X in the field and sets the field data value to 

10 indicate an X. 

In block 1413, the routine determines if there 
is a winner and if so, then the routine continues at block 
1414, else the routine continues at block 1415. In block 
1414, the routine draws a line through the grid to 

15 indicate the winning fields and set the variable winner. 
In block 1415, the routine sets the result code to the 
value TErrDealtWith to indicate that the TREV will not 
need to perform its standard processing for this event. 
The routine then returns. 

20 In a preferred embodiment, each user of the 

electronic mail system has access to the custom forms. In 
a local area network, the data structure for a form could 
be stored on a file server. Each user who sends and 
receives messages using a custom form would download the . 

25 form from the file server to create or view the message. 
The mail message that is sent would specify the custom 
form associated with the message. Alternatively, the 
custom form could be sent to the recipient as part of the 
mail message. In a preferred embodiment, each custom form 

3 0 has an associated icon. The mail system would display the 
icon to indicate that the custom form is available to the 
user. 

It will be appreciated that, although specific 
embodiments of the invention have been described herein 
3 5 for purposes of illustration, various modifications may be 
made without departing from the spirit and scope of the 
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invention. Accordingly, the invention is not limited 
except as by the appended claims* 
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